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REMARKS 

Claims 1-24 were pending in the application. By this paper, Claims 1,5, 19 and 23 have 
been amended, and new Claims 25-35 added. Accordingly, Claims 1-35 are presented herein for 
examination. 

Information Disclosure Statement (IDS) 

In response to Par. 3 of the Office Action, Applicant believes the two cited references to 
be merely background information regarding the general state of the broader art field, and not in 
any way material to patentability of the specific inventions claimed herein. 

Objections 

Regarding Par. 4 of the Office Action, Applicant has herein amended pages 3 and 4 of the 
Application as noted by the Examiner. Applicant submits that these amendments overcome the 
Examiner's objections, and add no new matter. 

§112Rejections 

In response to Par. 6 of the Office Action, Applicant respectfully traverses the Examiner's 
§1 12(1) rejections on multiple grounds. 

1) First, Applicant requests clarification of the Examiner's rejection, specifically 
regarding whether the rejection is lodged pursuant to §112(1) written description, §112(1) 
enablement, or both. The first two lines of Par. 6 of the Office Action refer to the rejection as 
being based on "the written description requirement", yet the discussion at the top of page 5 of 
the Office Action refers to the standard properly applied under an enablement rejection. See also 
the Examiner's own MPEP citation (Section 2106), which states in relevant part: 

"An application will be deficient under 35 U.S.C. §112, first paragraph when the 
written description is not adequate to identify what the Applicant has invented, or 
when the disclosure does not enable one skilled in the art to make and use the 
invention as claimed..." 
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As the Examiner undoubtedly recognizes, and the aforesaid MPEP passage unequivocally states, 
the "written description" and "enablement" standards of §112 are two distinct and non- 
coextensive bases for rejection , and hence Applicant cannot properly respond to such rejection 
5 without knowing which of said bases is being applied by the Examiner. 

However, notwithstanding the foregoing, Applicant further submits that the bases used by 
the Examiner (whether written description, enablement, or both) is moot, since Applicant's 
arguments and amendments presented herein overcome any and all such rejections (see 
discussions presented subsequently herein). 

10 

2) Second, Applicant respectfully traverses the Examiner's §112(1) rejection(s) on 
substantive grounds; i.e., that (i) Applicant was both in possession of the claimed inventions at 
the time of filing ("written description") and (ii) that the specification and drawings as filed 
enable one of ordinary skill in the field of integrated circuit/processor debug and simulation to 

15 practice the invention without undue experimentation ("enablement"). 

As a threshold matter, Applicant respectfully submits that the Examiner appears to have a 
conceptual error regarding what the recited "hardware process" comprises and how it/they relates 
to the claimed invention(s). The Examiner's reference to page 9, line 2 of Applicant's 
specification (see bottom of page 4 of the Office Action) refers to implementation of the debug 

20 methodology of the invention in hardware (e.g., rendering portions of the debug method 
functionality in an integrated circuit or the like), and not the target (e.g., hardware or 
software) processes being debugged . See Fig. 3, wherein the "target" hardware processes 304 
are clearly shown as different components from the debug process 302. In one exemplary 
embodiment, the recited targets or "hardware processes" of Applicant's invention comprise 

25 digital processors having an instruction set architecture and running an ordered set of instructions 
(aka, computer program), such processors being notorious in the art. 

Regarding item (i) above, Applicant refers the Examiner to Appendix I of the 
specification as filed, which comprises an exemplary computer program (code) implementing the 
30 various aspects of the claimed inventions, including in conjunction with the recited "hardware 
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processes ." See, e.g., lines 10-23 of page 17 (discussing non- simulator, aka "hardware" 
processes); line 31 of page 17; and lines 14, 31-32 and 58 of page 18. Applicant submits that this 
code represents unequivocal (per se) evidence of Applicant's possession of the claimed 
invention, since it is working code used to practice the claimed invention(s), including on 
5 hardware targets. 

Regarding item (ii) above, Applicant directs the Examiner's attention to the following 
exemplary citations from Applicant's specification as filed: 

10 "The present invention relates to the field of debugging programs in a 

distributed environment, such as a set of heterogeneous hardware processors 
(integrated circuits or In-Circuit Emulators) , and/or software-based simulators. " 
Page 1, lines 17-19 (Emphasis added; describing that the present invention is 
useful in, inter alia, debussing programs associated with heterogeneous 

1 5 hardware processors); 

" Multiprocessor systems complicate the debugging process significantly as 
compared to a unitary processor hardware environment . The most complex 
debugging environment is one in which the processors used in the multi-processor 
20 hardware employ different instructions sets . This condition is known to those 

skilled in the art as a heterogeneous multiprocessor system. " Page 2, lines 1-4 
(Emphasis added; describing that the aforementioned heterogeneous 
hardware processors have different instruction sets/ISAs); 

25 "Such method and apparatus would ideally be readily adaptable to a number of 

different hardware/software environments, would allow for ready transfer of 
information associated with one processor to the development/debug environment 
of another, thereby facilitating side-bv-side comparison of the operation of the 
different processors . " Page 2, lines 23-26 (Emphasis added; describing that the 

30 invention is useful in such heterogeneous hardware environments); 

"In one exemplary embodiment the environment comprises heterogeneous 
hardware digital processors (integrated circuits or In-Circuit Emulators) ,... the 
method further comprises initializing profile information, and incrementing the 
35 profile history after simulation (simulator) or execution (hardware) of one 

instruction . " Page 3, lines 5-13 (Emphasis added; describing that the 
"hardware process" is stepped by execution of an instruction on the 
processor); 

40 "The apparatus is adapted to run one or more of the aformentioned simulators 

and the debug program, and interface with one or more hardware processes 
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external to the apparatus via respective data interfaces . The engineer may then 
debug the multiple hardware processes using the debug program and simulation 
process(es), advantageously avoiding the need for multiple hardware/software 
environments for the debug and simulation processes/' Page 4, lines 1-6 
5 (Emphasis added; describing that communication with the "hardware 

process" is accomplished via a data interface); 

"As used herein, the term "processor" is meant to include any integrated circuit 
or other electronic device capable of performing an operation on at least one 

10 instruction word including, without limitation, reduced instruction set core 

(RISC) processors such as the ARC™ user-configurable core manufactured by 
the Assignee hereof central processing units (CPUs), and digital signal 
processors (DSPs). The hardware of such devices may be integrated onto a 
single piece of silicon ("die"), or distributed among two or more dies. 

15 Furthermore, various functional aspects of the processor may be implemented 

solely as software or firmware associated with the processor . " Page 4, lines 26- 
30 through Page 5, lines 1-3 (Emphasis added; describing that the processor of 
the exemplary "hardware process" may comprise on of Applicant's ARC 
cores, or any other type of processor now ubiquitous in the field); 

20 

"Instance variables relating to direct control of the target processor include, inter 
alia, setting and examining register values and the contents of memory; starting, 
stopping, and "single-stepping" the processor; setting hardware-controlled 
breakpoints; and similar operations . Registers are often employed by engineers 
(or the output of compilers) to hold working variables; i.e., those that are being 
operated upon. These registers frequently contain values of substantial interest to 
the design engineer/programmer. Consequently, it is important for the debug 
environment to provide access to such register values . " Page 6, lines 1-7 
(Emphasis added; describing the specific features and functions controlled 
within the target processor (aka "hardware process")); 

"So-called " single stepping" of a processor \ whether as a simulation process or a 
hardware process, permits engineers to follow the execution of the software to 
determine where implementation or design errors exist . Generally accepted 
35 debugging practice is defined, inter alia, in IEEE 1008-1987 IEEE Standard for 

Software Unit Testing and terms in IEEE Std 610.12-1990, Standard Glossary of 
Software Engineering Terminology (ANSI)." Page 6 ? lines 15-19 (Emphasis 
added; describing using well known "single stepping" procedures via a 
hardware process (e.g., digital processor)); 

40 

"In addition, it is possible to substitute the operation of actual hardware in place 
of a simulator or in-circuit emulator to permit continuous debugging as more 
information is gathered. " Page 7, lines 2-4 (Emphasis added; describing 
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substituting actual hardware (e.g., digital processor) in place of simulator or 
ICE); 

"Some digital processor families reserve a section of the processor instruction set 
for so-called "extended operations" or "extensions" which are typically 
implemented in customized sections of the hardware to perform application- 
specific functions such as Viterbi decode, FFT, and the like. " Page 7, lines 5-8 
(Emphasis added; describing "extensible" processors, such as Applicant's 
aforementioned ARC processor, that allow for user customization via the 
addition of extension instructions and associated hardware); 

"When the instance is an interface to a hardware processor, the libraries provide 
the functions for displaying the extension instruction in machine code listings . " 
Page 7, lines 10-12 (Emphasis added; describing use of machine code listings of 
extensions when using interfaces to hardware processes); 

"Associated with each running hardware process is an indication of when the 
status was last checked, and a variable delay interval indicating when it should 
next be checked . " Page 8, lines 15-17 (Emphasis added; describing how the 
debug process of the invention checks the separate hardware process(es)); 

"In the instance where all such running processes are executing on hardware 
processors, then each iteration through the status loop further includes an idle 
period designed to delay the debugger until at least one process is ready to be 
checked . " Page 8 5 lines 22-24 (Emphasis added; describing the case where all 
"processes" comprise hardware processes (e.g., processors)); 

"If no running processes are executing in simulators, then the program proceeds 
to step 124 to determine if any of the hardware processes were not yet ready to be 
checked, as indicated by the "need sleep" value set to "true". If all hardware 
processes have been checked, the program returns to step 104. " Page 10, lines 
28-30 through Page 11, lines 1-2 (Emphasis added; describing how the 
hardware processes are checked by the debug process using an exemplary 
"need sleep" parameter); and 

"Likewise, each hardware process 304 represents a single instruction set 
architecture within the heterogeneous multiprocessor system . These processes 
may be actual physical semiconductor devices, or an in-circuit emulator (ICE) of 
the type well known in the art. " Page 14, lines 2-5 (Emphasis added; describing 
how the "hardware processes" may be either a semiconductor (e.g., digital 
processor) or ICE of the type known in the art). 
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Applicant submits that the foregoing citations from its specification unequivocally set forth a) the 
construction of exemplary embodiments of the "hardware process" (e.g., a digital processor), and 
b) the use of the present invention in accessing and debugging such hardware processes. See, 
e.g., the computer code (Appendix I), which provides a detailed implementation of an exemplary 
5 embodiment of the debug process of the invention, including its interface with hardware 
processes . 

Applicant further notes that it is widely accepted that a claim need not be limited to a 
preferred embodiment. The Gentry Gallery, Inc., v. The Berkline Corporation, 134 F.3d 1473 
(Fed. Cir. 1998). 

1 0 Lastly, Applicant notes that irrespective of any of the foregoing, one of ordinary skill in 

the integrated circuit or processor debug fields would know how to interface and access a target 
hardware process (e.g., processor) without undue experimentation, such ability being ubiquitous 
in that art field. 

Accordingly, Applicant requests withdrawal of all §112 rejections set forth in the Office 

15 Action. 

§102 Rejections 

Per Par. 6 of the Office Action, Claims 1,19 and 23 stand rejected as being anticipated by 
20 Merks et al (U.S. 6,516,460). Applicant provides the following remarks. 

Claim 1- By this paper, Applicant has amended Claim 1 to include limitations relating to 

the act of continuously switching comprising switching without determining whether an event of 

interest has occurred. Applicant notes that in contrast, Merks teaches using a "waiting" step 150 

25 and check for a debug event as part of its polling or switching process. The approach of Merks 

thereby necessarily induces comparatively lengthy "wait" periods and checks for debug events; 

see, e.g., Col. 8, lines 10-19 of Merks: 

<( The "waiting" step 150 is limited by a timeout period to check for a debus: event . 
In a Windows NT embodiment, the debugger would check a debug event queue, by 
30 means of the WaitForDebuzEventf ) command, for the timeout period to see if a 

debus event has occurred . If a debug event had occurred during the execution of 
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that command or occurred before initiation of that command, the command would 
return an indication of the occurrence of a debug event because of the presence of 
a debug event of the queue. Otherwise, there would be no indication of a debug 
event. " {Emphasis added} 

5 

Applicant's invention as set forth in amended Claim 1 advantageously obviates any such debug 
event check, thereby greatly expediting the debug process, especially in the context of 
heterogeneous processes being debugged, where time is a critical attribute. 

10 Claim 19 - By this paper, Applicant has amended Claim 19 to include limitations relating 

to the recited method identifying a plurality of simulator processes. Support for this amendment 
is replete throughout Applicant's specification as filed. Applicant respectfully submits that Merks 
in no way teaches or suggests use of its invention in the context of a simulator. 

15 Claim 23 - By this paper, Applicant has amended Claim 23 to include limitations relating 

to the recited method being applied to extended digital processors . Support for this limitation is 
also replete throughout Applicant's specification; see, e.g., page 7, lines 5-12, and page 4, lines 
26-30 (the latter referring to Applicant's "ARC" extendable and user-configurable RISC 
processor). Applicant respectfully submits that Merks in no way teaches or suggests use of its 

20 invention in the context of debugging an extended digital processor. As noted on, inter alia, 
page 7, lines 5-12 of Applicant's specification, there are particular considerations relating to 
extended processor debug which are not present for other types of processors, and for which the 
invention of Claim 23 is particularly suited. 

25 §103 Rejections 

Claim 1- Per Par. 8 of the Office Action, Claims 2-18, 20-22, and 23-24 stand rejected 
over Merks et al (U.S. 6,516,460) in view of Davis, et al (U.S. 6,230,307). Applicant respectfully 
traverses these rejections based on (i) Applicant's amendment herein of Claim 1, and (ii) a lack 
of any suggestion to combine these two references. 
30 Regarding item (i), Applicant notes that Merks teaches using a "waiting" step 150 and 

check for a debug event as part of its polling or switching process as previously described. In 
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contrast, the inventions of Claims 2-13 import the limitations of Claim 1 as amended herein; i.e., 
the act of continuously switching comprising switching without determining whether an event of 
interest has occurred. Similarly, Applicant can find no discussion of polling or periodic switching 
as in Applicant's invention of Claim 1 in Davis. Hence, Merks and Davis cannot as a matter of 
5 law render amended Claim 1 (or its dependent claims) obvious, since not all of the limitations 
thereof are taught in either reference. 

Regarding item (ii), Applicant respectfully submits that there is no suggestion of any kind 
to combine Merks and Davis. As is well settled, a motivation or suggestion to combine two or 
more references is required in order to sustain an obviousness rejection under U.S. law. As set 

10 forth in the MPEP 2143.01, see In re Rouffet, 149 F.3d 1350, 1357, 47 USPQ2d 1453, 1457-58 
(Fed. Cir. 1998) (The combination of the references taught every element of the claimed 
invention, however without a motivation to combine, a rejection based on a prima facie case of 
obvious was held improper.). Applicant respectfully submits that in traversal of the Examiner's 
assertions regarding motivation (see, e.g., last paragraph of page 1 1 of the Office Action), the 

1 5 level of skill in the art cannot be relied upon to provide the suggestion to combine references . Al- 
Site Corp. v. VSI Int'l Inc., 174 F.3d 1308, 50 USPQ2d 1161 (Fed. Cir. 1999). 

Davis in no way teaches or even remotely suggests using any facet or portion of its 
invention for the purposes of debug (it makes only one passing reference to debug in the context 
of prior art development approaches). Rather, Davis deals entirely with dynamically relocatable 

20 hardware objects. 

Similarly, Merks in no way discusses teaches or suggests use of its invention with a 
simulator (emulator) such as, e.g., that of Davis. Hence, there is no suggestion to combine the 
two references from either reference. 

Therefore, Applicant respectfully submit that any obviousness rejection of Claim 1 (or its 

25 dependent claims) based on the combination of Merks and Davis must necessarily fail for, inter 
alia, lack of the requisite suggestion to combine. 

Claims 14, 20, 21, 22, and 24- Per Par. 8 of the Office Action, Claims 14, 20, 21, 22 and 
24 and their dependent claims stand rejected over Merks in view of Davis. Applicant respectfully 
30 traverses these rejections based on a lack of any suggestion to combine these two references. 
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Applicant respectfully submits that there is no suggestion of any kind to combine Merks 
and Davis. As previously noted, Davis in no way teaches or even remotely suggests using any 
facet or portion of its invention for the purposes of debug . Rather, Davis deals entirely with 
dynamically relocatable hardware objects. 

Similarly, Merks in no way discusses teaches or suggests use of its invention with a 
simulator (emulator), such as e.g., that of Davis. Hence, there is no suggestion to combine the 
two references from either reference. 

Therefore, Applicant respectfully submit that any obviousness rejection of Claim 1 (or its 
dependent claims) based on the combination of Merks and Davis must necessarily fail for, inter 
alia, lack of the requisite suggestion to combine. 

Claims 8 through 10 - Applicant respectfully traverses the Examiner's assertion or 
Official Notice (regarding Claims 5-14 on page 10 of the Office Action) that "extension 
instructions are reserved processor instruction set by the processor manufacturer, and hence 
would have been an obvious feature..". Applicant notes that none of the cited references teach or 
suggest extension instructions. As noted above regarding the Section 102 rejections, special 
consideration must be made of extended processor architectures with respect to the present 
invention. Hence, to merely say that the limitations of Claim 8-10 are an obvious feature in this 
manner both (i) provides no tangible basis or support for this contention, and (ii) is lacking a 
suggestion to combine, as noted above (which cannot be provided by level of skill in the art). 

Regarding Claims 20 and 21, Applicant did not find any substantive discussion of the 
following limitations of these claims in the Office Action: 

a) Claim 20 - . .selectively permitting at least a portion of said processes to 
operate while stopping others of said processes using a single one of said at least one 
interface." 

b) Claim 21 - ". . Jteratively obtaining execution profiling information from at 
least a portion of said processors; and 

optimizing the operation of said system based at least in part on said execution 
profiling information. " 
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Applicant therefore respectfully requests that the Examiner set forth the basis for the assertion 
that these limitations are taught in the prior art. 



these claims is supported by the specification as filed, and hence introduces no new matter. 
Other Remarks 

Applicant hereby specifically reserves the rights to prosecute claims of different or 
10 broader scope, including those cancelled herein, in a continuation or divisional application. 

Applicant notes that any cancellations or additions made herein and not substantively 
discussed above are made solely for the purposes of more clearly and particularly describing and 
claiming the invention, and not for purposes of overcoming art. The Examiner should infer no (i) 
adoption of a position with respect to patentability, (ii) change in the Applicant's position with 
15 respect to any claim or subject matter of the invention, or (iii) acquiescence in any way to any 
position taken by the Examiner, based on such cancellations or additions. 

Furthermore, any remarks made herein with respect to a given claim or amendment are 
intended only in the context of that specific claim or amendment, and should not be applied to 
other claims, amendments, or aspects of Applicant's invention. 
20 If the Examiner has any questions or comments which may be resolved over the 

telephone, he is requested to call the undersigned at (858) 675-1670. 



New Claims 



5 



By this paper, Applicant has added new Claims 25-35. Applicant submits that each of 



Respectfully submitted, 
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